1. Technical Field
The present application relates generally to an improved data processing system and method. More specifically, the present application is directed to an apparatus and method for automatic response time measurement of lightweight directory access protocol (LDAP) server operations.
2. Description of Related Art
A typical large enterprise has different types of systems, many installations of those systems, numerous types of information stored in those systems, and has a need to manage access to the information and to the systems themselves. One way of controlling such access is to make use of the Lightweight Directory Access Protocol (LDAP). LDAP is a widely used networking protocol for querying and modifying directory services running over Transmission Control Protocol/Internet Protocol (TCP/IP). An LDAP directory often reflects various political, geographic, and/or organizational boundaries, depending on the model chosen. LDAP deployments today tend to use Domain Name System (DNS) names for structuring the most simple levels of the hierarchy. Further into the directory hierarchy might appear entries representing people, organizational units, printers, documents, groups of people, or anything else which represents a given tree entry, or multiple entries.
There is much information about LDAP and LDAP directories available via the Internet and other information sources. One source of information on LDAP is the Web-based encyclopedia Wikipedia (www.wikipedia.org) from which much of the following background information was obtained.
LDAP is defined in terms of ASN.1 and protocol messages are encoded in the binary format Basic Encoding Rules (BER). LDAP uses textual representations for a number of ASN.1 fields/types, however. LDAP is used to access LDAP directories which follow the X.500 model comprising a tree of directory entries each consisting of a set of attributes. An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema. Each entry has a unique identifier, i.e. its Distinguished Name (DN), that consists of its Relative Distinguished Name (RDN), constructed from some attribute(s) in the entry, followed by the parent entry's DN. A DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a Universally Unique Identifier (UUID) is provided in the set of the entry's operational attributes.
An example entry may look like the following when represented in LDAP Directory Interchange Format (LDIF):
dn: cn=John Doe,dc=example,dc=com
cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 555 6789
telephoneNumber: +1 555 1234
mail: john@example.com
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
where dn is the name of the entry and is not an attribute nor part of the entry, “cn=John Doe” is the entry's RDN, and “dc=example,dc=com” is the DN of the parent entry. The other lines of the above example entry show the attributes in the entry. Attribute names are typically mnemonic strings, such as “cn” for common name, “dc” for domain component, and “mail” for e-mail address.
An LDAP server holds a subtree starting from a specific entry, e.g. “dc=example,dc=com” and its children. LDAP servers may also hold references to other servers, such that an attempt to access “ou=Some department,dc=example,dc=com”, for example, could return a referral or continuation reference to another LDAP server which holds that part of the directory tree. The client can then contact the other LDAP server. Alternatively, some LDAP servers also support chaining, which means the LDAP server contacts the other LDAP server and returns the results to the client.
A client, running a browser application, for example, starts an LDAP session by connecting to an LDAP server using a designated communication port, for example, default TCP port 389. The client then sends operation requests to the LDAP server and the LDAP server sends responses in return. With some exceptions, the client need not wait for a response before sending the next request and the LDAP server may then send the responses in any order.
The basic operations used with an LDAP server are, in order:                Bind—authenticate and specify LDAP protocol version,        Start TLS—protect the connection with Transport Layer Security (TLS) to have a more secure connection,        Search—search for and/or retrieve directory entries,        Compare—test if a named entry contains a given attribute value,        Add a new entry,        Delete an entry,        Modify an entry,        Modify DN—move or rename an entry,        Abandon—abort a previous request,        Extended Operation—generic operation used to define other operations, and        Unbind—close the connection, not the inverse of Bind.        
The client gives each request a positive Message ID, and the LDAP server response has the same Message ID. The response includes a numeric result code indicating success, some error condition, or some other special cases. Before the response, the LDAP server may send other messages with other result data, e.g., each entry found by the Search operation may be returned in such a message.
The Bind operation authenticates the client to the LDAP server. Simple Bind sends the user's DN and password in cleartext so that the connection may be protected using Transport Layer Security (TLS). The LDAP server typically checks the password against the userPassword attribute in the named entry. Anonymous Bind (with empty DN and password) resets the connection to an anonymous state. Bind also sets the LDAP protocol version.
The Start TLS operation establishes Transport Layer Security (the descendant of Secure Socket Layer (SSL)) on the connection which provides data confidentiality protection and/or data integrity protection. During TLS negotiation, the LDAP server sends its X.509 certificate to prove its identity and the client may do so as well. After proving their identities to one another, the client may then use an appropriate command to have this identity used in determining the identity used in making LDAP authorization decisions.
The Search operation is used to both search for and read entries. the Search operation parameters are:                baseObject—the DN (Distinguished Name) of the entry at which to start the search,        scope—baseObject (search just the named entry, typically used to read one entry), singleLevel (entries immediately below the base DN), or wholeSubtree (the entire subtree starting at the base DN).        filter—how to examine each entry in the scope, e.g., (&(objectClass=person) (|(givenName=John) (mail=john*)))—search for persons who either have given name John or an e-mail address starting with john.        derefAliases˜whether and how to follow alias entries (entries which refer to other entries),        attributes—which attributes to return in result entries.        sizeLimit, timeLimit—max number of entries, and max search time.        typesonly—return attribute types only, not attribute values.The LDAP server returns the matching entries and may return continuation references (in any order), followed by the final result with the result code.        
The Compare operation takes a DN, an attribute name, and an attribute value, and checks if the named entry contains that attribute with that value.
Add, Delete, Modify and Modify DN all require the DN of the entry to change. Modify takes a list of attributes to modify and the modifications to perform on each, e.g., delete the attribute or some values, add new values, or replace the current values with the new ones. Modify DN (move/rename entry) takes a new RDN (Relative Distinguished Name), optionally a new parent's DN, and a flag which indicates whether to delete the value(s) in the entry which match the old RDN.
An update operation, e.g., Add, Delete, Modify, or Modify DN, is atomic, i.e. other operations will see either the new entry or the old one. On the other hand, LDAP does not define transactions of multiple operations. Thus, if a client reads an entry and then modifies it, another client may have updated the entry in the mean time, i.e. before the modification.
The Extended Operation is a generic LDAP operation which can be used to define new operations. Examples include the Cancel, Password Modify, and Start TLS operations.
The Abandon operation requests that the LDAP server abort an operation named by a message ID. The LDAP server need not honor the request, except with search operations in progress. Unfortunately, the Abandon operation does not send a response. A similar Cancel extended operation has therefore been defined which does send responses, but not all implementations support this.
The Unbind operation abandons any outstanding operations and closes the connection. It has no response. Clients can abort a session by simply closing the connection or using the unbind operation.
As mentioned above, the contents of the entries in a subtree are governed by a schema. The schema defines the attribute types that directory entries may contain. An attribute definition includes a syntax. For example, a “mail” attribute might contain the syntax value “user@example.com”. A “jpegphoto” attribute may contain photograph(s) in binary JPEG/JFIF format syntax. A “member” attribute may contain the DNs of other directory entries. Attribute definitions also include whether the attribute is single-valued or multi-valued, how to search and/or compare the attribute, e.g., case-sensitive vs. case-insensitive, whether substring matching is supported, and the like.
The schema defines object classes. Each entry must have an objectClass attribute containing named classes defined in the schema. The named classes describe what kind of object an entry represents—e.g. a person, organization, domain, or the like. The named classes also identify which attributes the entry may contain and which attributes the entry must contain. Most schema elements have a name and a globally unique Object identifier (OID). LDAP server administrators may define their own schemas in addition to standard ones.
LDAP servers and LDAP directories, such as that described above, are used in many different types of electronic enterprise systems in today's information centered society. The various implementations of LDAP servers and LDAP directories cannot all be described herein, however FIG. 1, described hereafter, provides one example of an implementation of an LDAP server and LDAP directory. FIGS. 2 and 3 illustrate higher level interactions between client computing devices and an LDAP server.
FIG. 1 is an exemplary diagram illustrating one organization of a secure portal cluster environment in which an LDAP server is utilized. As shown in FIG. 1, the secure portal cluster environment 100 includes a portal server 110, a backend server 120, a policy server 130, and directory server 140. The secure portal cluster environment 100 is accessed by a user via the browser application 150 by way of the reverse proxy server 160. The reverse proxy server 160 includes a Tivoli Access Manager (TAM) WebSeal component 162 which is used to control access to the secure portal cluster environment 100 via a user logon process.
The portal server 110 includes International Technical Support Organization (ITSO) Bank Portlets 112 and WebSphere Portal 114 which provide user portal services for accessing the secure portal cluster environment 100. The backend server 120 includes ITSO Bank Enterprise Java Beans (EJBs) 122 and WebSphere application server 124 for providing the actual applications accessible via the user portal services of the portal server 110. The policy server 130 includes TAM policy server 132 and authorization server 134 which provide the policies and functionality for controlling access to protected resources of the secure portal cluster environment 100. The directory server 140 includes Tivoli Directory Server 142 which is an LDAP server that provides access to information in LDAP directory 144 for controlling access to protected resources. The Tivoli Access Manager and Tivoli Directory Server are available from International Business Machines, Inc. of Armonk, N.Y.
The TAM Webseal 162, portal server 110, and web application server 124 interact with the LDAP user registry via the Tivoli Directory Server 142. In this exemplary environment, the LDAP directory 144 contains user information accessible via the LDAP directory server, e.g., Tivoli Directory Server 142, that is used by the portal and application servers 110 and 124 to control access by users to protected resources.
The above implementation of an LDAP server and LDAP directory may be used, for example, to provide a centralized set of services to Web applications. In addition to a centralized approach, multiple LDAP servers can be utilized to provide services for the same set of services. In such an implementation, LDAP directory clients may be able to access whichever LDAP directory server is most conveniently located with respect to that client. An example of such a multiple LDAP server approach is shown in FIG. 2.
As shown in FIG. 2, LDAP servers for accessing the same set of LDAP directory objects may be distributed in different geographical locations, e.g., California, Paris, and Hong Kong. LDAP clients may access the particular LDAP server that is most conveniently located to that LDAP client. For example, both the California and Chicago based clients may access the California LDAP server, the Paris based LDAP client may access the Paris LDAP server, and the Moscow based LDAP client may access the Hong Kong LDAP server. Each of the servers may access associated LDAP directories that contain the same LDAP objects as each of the other LDAP server associated LDAP directories. That is, each LDAP server is a replica of each of the other LDAP servers.
Another alternative is to use multiple LDAP servers that are able to cooperate with each other to provide a service. In such an implementation, if a particular LDAP server is unable to fulfill a client request, the first LDAP server may refer the client to another LDAP server or be chained to another LDAP server so as to retrieve the necessary information from the other LDAP server. Such an approach is shown in FIG. 3.
As shown in FIG. 3, an LDAP client may send a first request for an individual with the name “Doe” and a salary greater than $50,000.00 to the California based LDAP server. The California based LDAP server may not contain any entries for an individual meeting these search requirements and may inform the LDAP client to direct its request to the Paris based LDAP server. In this implementation, the California and Paris based LDAP servers may be associated with LDAP directories that are not replicas of each other and thus, may contain different information.
In response to the referral to the Paris based LDAP server, the LDAP client may send its request as a second request to the Paris based LDAP server. As a response, the Paris based LDAP server may return the entries for “John Doe” and “Mary Doe” to the LDAP client.
Rather than sending a referral back to the LDAP client, however, in a chaining implementation, the California based LDAP server may automatically contact the Paris based LDAP server for the requested entries and may return them to the LDAP client as if the California based LDAP server had the entries in its own LDAP directory. This alternative is shown in FIG. 3 with dashed lines.
Web applications rely heavily on the LDAP server for user login, access control, personalization, address books, and the like. A large number of customer problems are related to the availability and performance of the LDAP server. Thus, it would be beneficial to have a mechanism for monitoring the availability and performance of LDAP servers, not only by themselves, but in the context of an entire business transaction.
One known solution for monitoring LDAP servers is to use a management application that uses the Simple Network Management Protocol (SNMP) network protocol to monitor the state of network devices. In another solution, a LDAP client application can be used to connect to a LDAP directory server and issue a search request for an entry. If the entry is returned within a reasonable span of time, the LDAP directory may be considered functional. This is known as “pinging” the LDAP directory.
In addition to the above, the operating system performance data may be monitored and/or log files may be analyzed to determine LDAP server performance. Monitoring the operating system can be useful when the LDAP directory server's performance is suffering because of an operating system problem. Analyzing the log files allows a monitoring application to scan the LDAP directory server's log files for messages that indicate an error condition and performance problem.
While these known solutions provide some information that is useful in identifying performance problems with regard to LDAP servers, they suffer from a number of drawbacks. First, none of the known solutions provides real time response time measurement for LDAP operations. Pinging the LDAP server may give an indication of operation response time, however what is being measured is synthetic invocation from a test client, not an actual invocation as it happens in a real time environment. Furthermore, none of the known solutions provides the ability to correlate between LDAP client and server operations. Moreover, none of the known solutions provides correlation among client operations.